< previous page page_206 next page >

Page 206
independence. Again, the AccountCreator class on Day 3 provided reasonable independence between the user-interface subsystem and the bank account product subsystem. The key concept here is to avoid making client classes and subsystems that invoke operations on implementation classes. Instead, try to use the services of interface classes.
Analyzing and Designing Subsystem Interfaces
Analysis for interface classes involves elaborating a business abstraction or concept often. This usually means analyzing use cases for key concepts, but also includes (but is not limited to) assessing the following:
Application performance requirements
Interactions with external and remote applications, servers, and components
User-interface requirements
Real-time, embedded system requirements (as you can now use Visual Basic to create Windows CE applications)
Note
The expression key concept should be understood to represent those business processes or entities that seem important to the user. A key concept is often repeated by the user during the interview. If you miss a key concept early in the process of creating the use cases, you'll definitely hear about it from the user during user acceptance testing.

You should design a subsystem interface in the form of interface classes. For instance, if you have to design an application to, among other things, communicate with a SQL Server relational database, you might design a class called IDatabase whose responsibility it is to allow flexible communications with it using remote data objects (RDOs), active data objects (ADOs/OleDB), data access objects (DAOs), or open database connectivity (ODBC) (Direct or API). Database subsystems are covered on Day 19, The Database Access Subsystem.
In general, IDatabase may have an important public method that looks like this:
Public Function openConnection(argConnectionString As _ String) As Boolean

End Function

 
< previous page page_206 next page >

If you like this book, buy it!